Add Charms.Constant.from_literal/5
#56
Conversation
WalkthroughThe pull request introduces several modifications across multiple modules in the Changes
Possibly related PRs
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (5)
lib/charms/jit.ex (1)
99-107: Consider adding documentation for error scenarios.The case statement handles different error scenarios well, but it would be helpful to document the expected error types and their handling. Consider adding a comment or
@docstring explaining:
- When a CompileError vs. original error is raised
- The structure of diagnostic messages
- Examples of common error scenarios
Example documentation:
# Handles three scenarios: # 1. Success: Returns the JIT engine # 2. MLIR diagnostic error: Raises CompileError with diagnostic message # 3. Other errors: Reraises the original error with stack tracelib/charms/diagnostic.ex (1)
12-20: Consider handling meta_from_loc errorsThe function should handle potential errors from
meta_from_locto prevent crashes when location parsing fails.Consider wrapping the metadata extraction in a
try/rescue:def compile_error_message(%Beaver.MLIR.Diagnostic{} = d) do txt = to_string(d) case txt do "" -> {:error, "No diagnostic message"} note -> - {:ok, meta_from_loc(MLIR.location(d)) ++ [description: note]} + try do + {:ok, meta_from_loc(MLIR.location(d)) ++ [description: note]} + rescue + e in ArgumentError -> + {:error, "Failed to extract location: #{Exception.message(e)}"} + end end endlib/charms/constant.ex (2)
1-2: Consider adding module and function documentation for clarityAdding
@moduledocand@docannotations to the module and its functions can enhance the readability and maintainability of the code by providing explanations of their purposes and usage.
23-26: Ensure error handling provides clear and consistent messagesThe error message in the
raise CompileErrorstatement is informative. Verify that it aligns with the project's error handling conventions for consistency across the codebase.lib/charms/kernel.ex (1)
58-61: Refactoring to utilizeCharms.Constant.from_literalenhances code maintainabilityReplacing
constant_of_same_typewithCharms.Constant.from_literalcentralizes constant creation logic, simplifying the code and promoting reuse.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
lib/charms/constant.ex(1 hunks)lib/charms/defm/definition.ex(1 hunks)lib/charms/defm/expander.ex(1 hunks)lib/charms/diagnostic.ex(1 hunks)lib/charms/jit.ex(2 hunks)lib/charms/kernel.ex(3 hunks)test/const_test.exs(1 hunks)test/defm_test.exs(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- lib/charms/defm/definition.ex
- test/defm_test.exs
🔇 Additional comments (5)
lib/charms/jit.ex (1)
85-98: LGTM! Improved error handling with diagnostic messages.
The enhanced error handling now properly captures and utilizes MLIR diagnostic messages while preserving stack traces. This will make debugging easier and provide more context when errors occur.
test/const_test.exs (1)
19-19: Updated error message aligns with new constant handling logic
The adjusted error message accurately reflects the changes in how unsupported constant types are handled, improving clarity in error reporting.
lib/charms/kernel.ex (2)
8-8: Addition of division operator :/ is appropriate and correctly implemented
Incorporating the division operator into @binary_ops expands functionality and aligns with the supported binary operations.
42-44: Implementing division operation using Arith.divsi
The use of Arith.divsi for signed integer division is appropriate. Ensure that operand types are correctly managed to prevent unexpected behavior.
lib/charms/defm/expander.ex (1)
1213-1213: Refactoring constant creation to use Charms.Constant.from_literal improves clarity
Utilizing Charms.Constant.from_literal streamlines the expand_macro function, enhancing readability and maintainability.
Summary by CodeRabbit
New Features
Bug Fixes
constmacro.Refactor
expand_macrofunction.Tests